A popular way of creating software is using abstract models. An abstract model defines various aspects of a system's behavior at a design level before a developer writes any source code. For example, the abstract model may define the major components of the design and the interfaces between components. Abstract models can also define finer details of software, such as the names of each class that will be in the design, the variables associated with each class, function names and parameters, and so forth. A recent movement called Model-Driven Engineering (MDE) is the systematic use of models as primary engineering artifacts throughout the engineering life cycle. Engineers can apply MDE to software, system, and data engineering. As it pertains to software development, MDE refers to a range of development approaches that are based on the use of software modeling as a primary form of expression. With the introduction of the Unified Modeling Language (UML), MDE has become very popular with a wide body of practitioners and there are many available supporting tools. More advanced types of MDE have expanded to permit industry standards that allow for consistent application and results. The continued evolution of MDE has added an increased focus on the use of models and their role in software development.
Modeling is not useful without a relationship to the eventual building of software code. Therefore, modeling tools are often capable of generating source code from the model. Model-generated source code gives a developer a head start in developing a software system and reduces the chance for errors since the generated code is a close reflection of the model. However, models are insufficient to completely implement the software system, so the developer must often modify the generated code or add additional code to complete the implementation of the system. Often the product is built in two distinct stages: (1) designing and modeling with a modeling tool that ultimately generates a coding framework, and (2) implementing the product based on the generated code.
Unfortunately, the model and source code can quickly become out of sync. If the developer makes changes to the model, then regenerating the generated code based on the model changes may overwrite changes to the generated code made by the developer or may cause developer-added code to fail to interoperate with the regenerated code. As the developer changes a declaration in his abstract model, he is required to (1) manually change all uses of that declaration in other parts of the model, (2) manually trigger a re-generation of all of the generated source code, and (3) manually update all of the additional source code to reflect the change. If the developer makes changes to the code first, then to keep the model in sync he is required to (1) manually perform the same change in the model that corresponds to the change he made in the developer code, (2) manually change all uses of that declaration in other parts of the model, (3) manually trigger a regeneration of all of the generated source code, and (4) manually update all of the developer source code to reflect the change. The large number of manual steps can lead to errors and consume valuable development time.